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DETAILED ACTION 

1 . This action is responsive to communications: RCE filed 10/21/05 to the 
application filed on 6/16/00, priority filed 6/16/99. 

2. Claims 1-8, 11,19-20, 22-23, 27-28, 36 are pending in the case. Claims 1,11, 
19, 26, and 36 are independent claims. 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 

5. Claims 1-8, 1 1 ,19-20, 22-23, 27-28, 36 remain rejected under 35 U.S.C. 103(a) 
as being unpatentable over Markus et al. (US Pat No. 6,490,601 B1 , 12/3/02, filed 
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1/15/99) in view of Mohan et al. (US Pat App Pub No. 2003/0140312 A1 , 7/24/03, filed 
11/26/02, priority 5/14/99). 

Regarding independent claim 1 , Markus discloses: 

- creating a user profile associated with a user, wherein said user profile includes 
user data (figure 6, #604, #608: retrieving user's raw data profile and merging 
user's raw data profile with mapping table inherently show that each of a plurality 
of user profiles are created and stored in memory so that the user data profiles 
including user data can be retrieved or used later) 

- obtaining an electronic form having a field to be completed (col 5, lines 1-12, 29- 
35: "a form mapping containing a set of associations between fields in the 
electronic form "...enabling automatic insertion of user information into an 
electronic form having multiple fields ...") 

- dynamically generating a form map, wherein the form map identifies an 
association between the user data and the field in the electronic form (col 5, 
lines 1-55: "A form mapping containing a set of association between fields in the 
electronic form ... Each raw data file containing data strings, each data string 
corresponding to a pre-named field. Each raw data file is associated with a 
registered user ... The form mapping is utilized to attach a data string to the field 
in the electronic form where the pre-named field and the field in the electronic 
form have been previously matched or mapped ... a form mapping is utilized to 
attach a data string to the field in the electronic form ... comparing data relating 
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to the field in the electronic form..."; since each user has different raw data file, 
generating such form map varies according to each user data file, said 
generating is performed dynamically according to each user; col 14, line 30 to 
col 16, line 28: "... the user cookie is used to obtain the user's raw data, which 
includes actual data values and preferences associated with each data value. 
The practices mentioned above associated with legacy names and the 
preferences associated with user raw data values are stated in terms of 
conditions mapping data into the form is performed according to the form 
map where the form map (or the form mapping) varies according to various 
conditions and preferences from each user inherently shows that the form map is 
generated dynamically according to various conditions and preferences from 
each user) 

- obtaining the user profile from a fill server (col 5, lines 29-41, 45-55: "a server for 
enabling automatic insertion of user information into an electronic form having 
multiple fields ... The server contains a memory area storing multiple raw data 
profiles where each raw data profile corresponds to a registered user "the 
raw data profile includes several standard field names, each standard field name 
having a corresponding data string and a use-preference data item determined 
by a registered user...") 

- completing the field according to the form map with the user data (figure 4B, 
#440, [0099]: "Browser transmits filled out electronic form document inherently 
shows completing a field according to the form map for a field in the electronic 
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form with the user data in the raw data file; col 6, line 63 to col 7, line 23: filling 
a form with data from the privacy bank shows completing the field in the form 
with the user data according to the form map) 
Markus does not disclose: 

- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field 

- updating the user profile with the user entered data 
Mohan discloses: 

- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field ([0095]: user enters data not found in the user's 
profile to the form) 

- updating the user profile with the user entered data ([0095], [0096], [0102]: 
storing the form submitted with user-entered information to the IIM at server 
where the user-entered data can be data not found in the user's profile implies 
that data in the user profile at IIM is updated with the user-entered data) 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
was made to have combined Mohan into Markus for automatically updating the user 
profile with user-entered data which is not found in the user profile. Thus, users do not 
have to remember to update the user profile every time they enter a new data not in the 
user profile before. 
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Regarding claim 2, which is dependent on claim 1, Markus discloses that obtaining a 
user profile includes: 

- transmitting a user identification and a signature of the electronic form to a fill 
server (col 8, lines 1-14: "User 302 informs privacy bank server 308 of the 
identity of the user and of which Web site and which form on that Web site (if 
more than one) the user wishes to have filled in. This information is transmitted 
to privacy bank server . . .") 

- obtaining the user profile from the fill server, wherein the user profile corresponds 
to the user identification (col 8, lines 40-64: the raw data profile storage area 
328, one of the components of the privacy bank server which enables to fill in the 
electronic form on a remote user computer, includes the data profile for each 
registered user) 

Regarding claim 3, which is dependent on claim 2, Markus discloses that the user 
identification includes a user ID and a user password (col 8, lines 40-64: "a registered 
user has an unique account that can be used as an identifier and a password..."). 

Regarding claim 4, which is dependent on claim 2, Markus discloses that the electronic 
form signature includes a text string having a uniform resource locator of the electronic 
form (col 7, lines 40-62: "a purchasing form, typically an HTML document, is returned 
and downloaded into and displayed in a browser window..."; the fact that the purchasing 
form is a HTML document inherently shows that the HTML document, which includes 
the electronic form, has an uniform resource locator; col 11, lines 43-49: the user 
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identifier and the URL for identifying the document containing the form; col 13, lines 38- 
48: the identifier of the electronic form contains the identifier of the merchant's Web site 
in the form of a URL). 

Regarding claim 5, which is dependent on claim 4, Markus discloses that the electronic 
form signature includes a descriptor of the one or more fields of the electronic form (col 
17, lines 8-15: the name strings or field names or guides to entering data in an 
electronic form; col 9, lines 1-13: the field names are the descriptors of the fields in an 
electronic form). 

Regarding claim 6, which is dependent on claim 4, Markus discloses that the electronic 
form signature includes a descriptor of form field requirements (col 11, lines 39-49: the 
fact that the URL which is used by the privacy bank server to determine how the 
electronic form document should be filled implies that said URL, which is the electronic 
form signature, contains a descriptor of form field requirements). 

Regarding claim 7, which is dependent on claim 1, Markus discloses that the user 
profile is represented by a graphical icon on a display screen and wherein the user data 
is transferred to the electronic form on manipulation of the graphical icon within the 
display screen (col 11, lines 15-22: ".. by clicking on the autofill button, the user allows 
the browser to execute the shippable code or profile stored thereon..." ). 
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Regarding claim 8, which is dependent on claim 1, Markus discloses that the user 
profile includes shippable code embodying the user data corresponding to the fields of 
the electronic form, and wherein completing at least one of the fields of the electronic 
form includes executing the shippable code to complete at least one of the fields of the 
electronic form (col 5, lines 29-44). 

Regarding claim 11, which is dependent on claim 1, Markus discloses: 

- displaying a second application indicative of the user profile containing data 
corresponding to at least the field of the electronic form according to the form 
map (figure 4A, #408-418: the fact that the browser for displaying the electronic 
form connects with the privacy bank and gets cookie and user data 
corresponding to the cookie from the privacy bank server inherently shows that 
the user profile data of the privacy bank server is displayed in a different window 
in a second application; col 10, lines 1-35 and col 8, lines 19-39) 

Regarding claim 19, which is dependent on claim 1, Markus discloses: 

- generating a fill bundle corresponding to a merger of data within at least one of 
the user profile and the form map corresponding to a form signature, wherein the 
fill bundle is embodied in a graphical representation (figure 6, #608 Server 
merges mapping table with user's raw data profile, #610 Server converts merger 
into shippable code and col 13, line 49 to col 14, line 29: generating a 
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shippable code in the form of a JavaScript program where the shippable code, 
converted from the merger of legacy bank name and raw data value associated 
with one of a plurality of users, is used to fill in the form on the user browser; the 
shippable code bundles data for filing the electronic form, and is corresponding to 
a fill bundle) 

Regarding claim 20, which is dependent on claim 1, Markus discloses obtaining the 
user profile corresponding to a user identification from a database having one or more 
user profiles organized according to the user identification (figures 3A-B and col 8, 
lines 40-64: raw data profile contains sets of data relating to registered user of the 
privacy bank service where a registered user has a unique account number as a user 
identification). 

Regarding claim 22, which is dependent on claim 1, Markus discloses that if the form 
map database does not have a form map corresponding to the form signature, 
generating a new form map based upon the form signature (col 13, line 49 to col 14, 
line 4: the privacy bank server uses the URL or other identifier for the specific form to 
be filled out to retrieve a mapping of each field name in the electronic form to privacy 
bank standardized names; the merchant submits one or more forms to privacy bank 
which then examines each field name in the forms and matches it with a privacy bank 
field name; the fact that if the legacy name does not match the privacy bank field 
names, then the privacy bank user raw data can be updated to include the legacy name 
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based upon the identifier of the form indicates that when the privacy bank server whose 
form map database does not have the form map of the newly submitted form from the 
merchant, the privacy bank raw data is updated to include the newly created form map 
of the new form based upon the corresponding URL or the form signature). 

Regarding claim 23, which is dependent on claim 19, Markus discloses that the fill 
bundle includes shippable code containing commands for completing one or more 
corresponding fields of the electronic form (col 14, lines 5-29: "normally browser 
programs have a JavaScript component that is manipulate by JavaScript commands. 
These JavaScript commands in the shippable code are used to fill in the electronic form 
on the browser, a technique well known in the field of Internet and Java 
programming.."). 

Regarding claim 27, which is dependent on claim 1 , Markus discloses that the system 
further comprises a user information server in communication with the fill server and 
providing user profile data to the fill server (col 7, line 63 to col 8, line 39: the fact that 
the Markus system has the capability of providing user profile data and creating fill 
bundle embodied in shippable code for filling data in the user profile to electronic forms 
in a remote computer inherently shows that the Markus system includes a user 
information server in communication with the fill server). 
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Regarding claim 28, which is dependent on claim 1, Markus discloses a form map 
server in communication with the fill server and providing form maps corresponding to at 
least one field of an electronic form, wherein a graphical representation includes a 
merger of the form map and the user profile data (figure 6 and col 13, line 49 to col 
14, line 29: the merger of mapping table, including form map, with user's raw data 
profile in a user's browser shows that the graphical representation of the browser 
window includes the merger; the mapping table retrieved from the privacy bank 
database connected to the user's browser where to display the form and the web site 
that contains the form and to fill in the form inherently shows that the privacy bank 
database which stores the table of form mapping is considered as a form map server, 
and the privacy bank server is where to create the fill bundle embodied in shippable 
code is considered as the fill server). 

Regarding independent claim 36, Markus discloses: 

- creating a user profile associated with a user, wherein said user profile includes 
user data (figure 6, #604, #608: retrieving user's raw data profile and merging 
user's raw data profile with mapping table inherently show that each of a plurality 
of user profiles are created and stored in memory so that the user data profiles 
including user data can be retrieved or used later) 

- obtaining an electronic form having at least a field to be completed (col 5, lines 
1-12, 29-35: "a form mapping containing a set of associations between fields in 
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the electronic form "...enabling automatic insertion of user information into an 
electronic form having multiple fields ...") 
- dynamically generating a form map, wherein said the form map identifies an 
association between the user data and the field in the electronic form (col 5, 
lines 1-55: "A form mapping containing a set of association between fields in the 
electronic form ... Each raw data file containing data strings, each data string 
corresponding to a pre-named field. Each raw data file is associated with a 
registered user . . . The form mapping is utilized to attach a data string to the field 
in the electronic form where the pre-named field and the field in the electronic 
form have been previously matched or mapped ... a form mapping is utilized to 
attach a data string to the field in the electronic form ... comparing data relating 
to the field in the electronic form.."', since each user has different raw data file, 
generating such form map varies according to each user data file, said 
generating is performed dynamically according to each user; col 14, line 30 to 
col 16, line 28: "... the user cookie is used to obtain the user's raw data, which 
includes actual data values and preferences associated with each data value. 
The practices mentioned above associated with legacy names and the 
preferences associated with user raw data values are stated in terms of 
conditions ..."; mapping data into the form is performed according to the form 
map where the form map (or the form mapping) varies according to various 
conditions and preferences from each user inherently shows that the form map is 
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generated dynamically according to various conditions and preferences from 
each user) 

- obtaining the user profile from a fill server (col 5, lines 29-41, 45-55: "a server for 
enabling automatic insertion of user information into an electronic form having 
multiple fields ...The server contains a memory area storing multiple raw data 
profiles where each raw data profile corresponds to a registered user "the 
raw data profile includes several standard field names, each standard field name 
having a corresponding data string and a use-preference data item determined 
by a registered user...") 

- completing the field according to the form map with the user data (figure 4B, 
#440: "Browser transmits filled out electronic form document inherently shows 
completing a field according to the form map for a field in the electronic form with 
the user data in the raw data file; col 6, line 63 to col 7, line 23: filling a form 
with data from the privacy bank shows completing the field in the form with the 
user data according to the form map) 

Markus does not disclose: 

- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field 

- updating the user profile with the user entered data 
Mohan discloses: 
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- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field ([0094]: user enters data not found in the user's 
profile) 

- updating the user profile with the user entered data ([0095], [0096], [0102]: 
storing the form submitted with user-entered information to the MM at server 
where the user-entered data can be data not found in the user's profile implies 
that data in the user profile at IIM is updated with the user-entered data) 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
was made to have combined Mohan into Markus for automatically updating the user 
profile with user-entered data which is not found in the user profile. Users, thus, do not 
have to remember to update the user profile every time they enter a new data not in the 
user profile before. 

Response to Arguments 

6. Applicant's arguments filed 10/21/05 have been fully considered but they are not 
persuasive. 

Applicants argue that Mohan does not disclose "updating the user profile with the user 
entered data" since only the transaction database, not the user profile, is updated with 
the user entered data, and the transaction database and the user profile are not "one-in- 
the-same or interchangeable, as the Examiner has implied" (Remarks, page 5). 



Application/Control Number: 09/595,622 Page 15 

Art Unit: 2178 

Examiner agrees that the transaction database and the user profile in Mohan are "not 
one-in-the-same or interchangeable." The Examiner does not imply that the transaction 
database and the user profile are "one-in-the-same" as Applicants said. 
The Examiner just would like to point out that updating the transaction database leads 
to the change of the user profile (paragraph 92: the recording of the transaction 
database is dated as changes to the user profile) where updating the transaction 
database is due to entering data by a user where said entered data is not included in 
the user profile before (paragraph 95) and then the newly entered data is stored in the 
transaction database (paragraph 96). This shows that the user profile and the 
transaction database have some common data such that when data in the transaction 
database is updated with the entered data, the data in the user profile is also changed, 
which means updated. In other words, updating the user profile with the user entered 
data is performed as claimed via updating data in the transaction database. 

Conclusion 

7. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

Lawton et al. (US Pat No 5,823,100, 1 1/3/98). 
Fernando et al. (US Pat No 6,193,152, 2/27/01, filed 5/9/97). 
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8. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Cong-Lac Huynh whose telephone number is 571-272- 
4125. The examiner can normally be reached on Mon-Fri (8:30-6:00). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Stephen Hong can be reached on 571-272-4124. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-4125. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 




Cong-Lac Huynh 
Primary Examiner 
Art Unit 2178 
12/5/05 



